In many large and small enterprises, as illustrated in FIG. 1A, it is common for a central server, e.g., 110a, to provide advanced communication software tools or applications 120a to a plurality of clients 112a in the enterprise 100a. Such applications or tools 120a can support for example, file sharing, on-line polling, on-line questionnaires, intra-office communications, scheduling and calendaring, and information postings/announcements. For example, a user 130a of a client 112a can launch a meeting scheduler tool 120a residing on the central server 110a to schedule a meeting with several enterprise attendees. The tool 120a can allow the user 130a to select the attendees and to propose several times and days for the meeting. The tool 120a can then send the proposal to the attendees, allow each attendee to select one or more of the proposed times and days, compile the responses, and determine a mutually convenient meeting time and day based on the responses.
In another example, company wide information can be disseminated or made available to the clients 112a through the central server 110a. An announcement tool 120a can post Information concerning functions, meetings and seminars, such as meeting rooms, times, and scheduled speakers, on the enterprise's 100a internal website hosted by the central server 110a and accessed by any of the clients 112a. In another example, clients 112a can access files or documents stored in a central database 140a via the central server 110a. The central server 110a can support many other applications and tools 120a for the enterprise 100a and for the clients 112a therein, and those described above are but a few examples.
Typically, for security reasons, the central server 110a resides behind at least one firewall 150a insulated from a public network 160, such as the Internet. As a result, the central server 110a generally is not accessible by an external client 112b, i.e., a non-enterprise client, due to complications related to firewall traversal, authentication and access control. While this scheme protects the central server 110a from malicious users and viruses, it also precludes access by friendly external clients 130b, e.g., customers, vendors, and partners who have business relationships with the enterprise 100a. Thus, customers 130b who are invited to a meeting at the enterprise 100a would not be allowed to access the enterprise's internal website to find the meeting room and time. Such information would need to be provided outside of the enterprise 100a, e.g., on a website hosted by a server outside of the firewall 150a, where the information would be available to the public. This is not a desirable solution if the meeting involves sensitive and/or confidential matters.
To address some of these concerns, an independent service provider 170, on the Internet, illustrated in FIG. 1B, can offer enterprise-to-enterprise communication tools and applications 120c. The independent service provider 170 acts like a central server in that it controls the application 120c, e.g., on-line polling, on-line questionnaire, meeting scheduler, and file sharing, and routes all network traffic between enterprises 100a, 100b, and through firewalls 150a, 150b, if needed. To that extent, the independent service provider 170 can create supposedly secure communication channels for the information exchange. Nevertheless, because the independent service provider 170 is responsible for sign-in authentication for all attendees where individual enterprises have no control, it is susceptible to a security breach and therefore, the enterprises 100a, 100b using the service can be potentially exposed to identity and virus issues.
In both of the systems described above, the central servers 110a, 110b and independent service provider 170 are generally isolated from other central servers and service providers. The clients registered on different servers or different service providers are isolated from one another. To connect clients who are using difference services requires yet another communication process for service invitation, and this process can be different from enterprise 100a to enterprise 100b. As a result, the application scope of these centralized services can be very limited in terms of the number of clients 112 and enterprises 100a, 100b who are accessing the same service at the same time and who are trying to communicate with each other. This limitation has serious impact to applications in vertical industries, where many enterprises are involved together for business collaborations. Their interactions can follow a “star” model or a “mesh” model, depending on the business relationships. Complicated connection setups between centralized services can cause severe scalability problems among enterprises that have flexible and dynamic collaboration models. In short, the centralized environment is not scalable and typically involves a single enterprise 100a, 100b or a limited number of enterprises. Therefore, the central server solution is not suitable for a vertical industry that can have hundreds of thousands of employees and partners residing in different offices in different countries and continents.
Accordingly, there is a need for a system and method that not only allows users within an enterprise to utilize advanced communication applications and tools within the enterprise, but also allows the users to utilize the same tools with users in different enterprises without requiring a centralized independent service provider to connect services across enterprises. The system should be scalable and should regulate traffic according to enterprise security policies. The system should be adaptable by a large number of enterprises who are conducting business collaborations with each other dynamically in a de-centralized, i.e., distributed, environment.